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DETAILED ACTION 



Response to Arguments 

1. Applicant's arguments with respect to claims 1-4, 6-8, 10-17, 37 and 39-41 have been 
considered but are moot in view of the new ground(s) of rejection. 

Claim Rejections - 35 USC §103 

2. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

3. Claims 1-4, 6-8, 10-17, 37 and 39-48 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Klimenko (US Pat 5,974,547) in view of Cox et al. (US 5,349,643), K. R. 
Soilings, "The TFTP Protocol (Revision If (hereinafter RFC 783), and Bailey et al. (US 
6,185,623). 

Regarding claims 1, 16, 37, 41, 43 and 46, KHmenko discloses a technique for reliable 
booting of an operating system to a client computer. The cUent computer contains a LAN 
adapter, also referred to as a network interface card-NIC (col. 7, lines 1 1-16). This NIC 
represents the router card of the present invention. The server (50) represents the system 
controller of the present invention and the network (30) represents the bus of the present 
invention (see Figure 2A). The chent computer will issue a trivial file transfer protocol (TFTP) 
request to server (50) by way of the NIC. The TFTP server locates and opens this file based on 
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the information provided in the TFTP request, then downloads this boot file, LANHD.EMG, to 
the client computer. The PC acknowledges successful download by sending an 
acknowledgement packet to the server (col 11, lines 12-26). Klimenko fails to expressly 
disclose that the information used to locate the file is a port address and file type, and that the 
server transmits file size to the NIC. Klimenko also fails to disclose performing this process for 
an inactive router card in addition to an active router card. Cox discloses a client/server system 
wherein the client may request a boot image from a server (col. 2, line 63 - col. 3, line 27). Cox 
provides no disclosure for sending a file name in the request for the boot image. RFC 783 
discloses a format for TFTP packets that demonstrates a TFTP request packet containing a 
source port address (see I Appendix). Bailey discloses a system for booting a client computer 
from a server that uses the TFTP. In this system the client may include a transfer size request in 
the TFTP request packet, in which case the server responds to the request packet with the 
transfer size (col. 4, line 58 - col. 5, line 36). The purpose of requesting the transfer size is to 
determine the amount of memory needed to store a file (col. 1 1, Unes 57-67). This constitutes 
setting up a buffer size of at least as large as the file size. Bailey also discloses a subnet group of 
clients wherein one cUent is the master cUent, representing the active router card of the present 
invention, while any other clients in the group represent an inactive router cards (col. 6, lines 25- 
40 and col. 7, lines 35-56). At the time the invention was made, it would have been obvious to a 
person of ordinary skill in the art to modify the request packet to use only the file type, and not 
the whole file name and to include the port address to identify the file to be sent to the NIC of 
Klimenko. As Klimenko discloses in Fig. 4A, there is only one image file (250) for a particular 
client, thus it would have been obvious that the whole file name is unnecessary in requesting the 
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image file. It also would have been obvious to send the file size to the NIC. It would have been 
obvious to have a master client and at least one other client that were sending requests to the 
server of Klimenko in order to download an image file. One of ordinary skill in the art would 
have been motivated to use the port address to first locate the directory corresponding to the 
particular client NIC in the server. One of ordinary skill in the art would have been motivated to 
use the file type, image, and not the whole file name to determine which file in the directory to 
send in order to simplify the request process for the NIC. One would have been motivated to 
send the file size to the NIC so that the cHent would be able to set aside enough memory to store 
the image file. One of ordinary skill in the art would have been motivated to have a group of 
clients containing a master client in case the group of clients all needed to download the same 
image file in order to use a common operating system. 

Regarding claims 2 and 17, Klimenko discloses using trivial file transfer protocol (TFTP) 
to make the request for the image file. Klimenko also discloses that a TFTP acknowledgement 
packet is sent to the server when the client successfially downloads the file (col. 11, lines 17-22). 
Klimenko fails to expressly disclose forming a data packet from the file, wherein the data packet 
is a fixed size and includes a system frame header and a data packet protocol header. RFC 783 
discloses that TFTP uses packets of fixed length blocks (page 3). Figure 3-1 : Order of Headers 
(page 5) shows a header structure including Local Medium and Internet headers, which 
collectively represent the system frame header of the present invention, and Datagram and TFTP 
headers, which represent the data packet protocol header of the present invention. TFTP also 
specifies that each data packet must be acknowledged by an acknowledgement packet before the 
next packet can be sent (page 3). At the time the invention was made, it would have been 
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obvious to a person of ordinary skill in the art to use the fixed size TFTP packet format with the 
appropriate headers in sending data packets formed from the requested file. One of ordinary skill 
in the art would have been motivated to do this because this protocol is small and easy to 
implement for the purpose of transferring files. 

Regarding claim 3, Klimenko fails to disclose sending a last packet less than the fixed 
size. RFC 783 discloses that a data packet of less than 512 bytes, which is the fixed size, signals 
the termination of a transfer (page 3). At the time the invention was made, it would have been 
obvious to a person of ordinary skill in the art to use this last packet smaller that 512 bytes at the 
end of the file transfer in the invention of Klimenko. One of ordinary skill in the art would have 
been motivated to do this to signal to the NIC that the transfer was complete so that the NIC 
could start using the downloaded file. 

Regarding claim 4, Klimenko fails to disclose retransmitting a data packet to the client if 
the server receives a duplicate acknowledgment packet for the previous packet. RFC 783 
discloses that a lost data packet causes a timeout for the intended recipient, in which case the 
intended recipient retransmits its last packet (page 3). Thus, if the intended recipient is the client 
and a timeout condition occurs, the client would then send an acknowledgement packet for the 
previously received data packet, i.e. a duplicate acknowledgment. At the time the invention was 
made, it would have been obvious to a person of ordinary skill in the art to retransmit a data 
packet formed from the image file of Klimenko in response to receiving a duplicate 
acknowledgement packet. One of ordinary skill in the art would have been motivated to do this 
in order to signal the server that a data packet has not been received and needs to be 
retransmitted. 
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Regarding claims 6, 40, 45 and 48, Klimenko does not expressly disclose a system frame 
header and a data packet protocol header consisting essentially of an operation code, a block 
number, a file type and a checksum. RFC 783 discloses a header structure in Figure 3-1 : Order 
of Headers (page 5) of Local Medium and Internet headers, which represent the system frame 
header of the present invention, and the Datagram and TFTP headers represent the data packet 
protocol header of the present invention. The format for a data packet includes an opcode and a 
block # (see Figure 5-2, page 10). Additionally, TFTP specifies that it may be implemented on 
top of the Internet User Datagram Protocol (UDP or Datagram) (page 2). The User Datagram 
Header includes a checksum (page 15). Thus, this checksum would be included in the data 
packet protocol header. RFC 783 also specifies that a request (RRQ) packet includes a filename 
in the header. This filename represents the file type of the present invention because the file type 
is provided in the filename extension. At the time the invention was made, it would have been 
obvious to a person of ordinary skill in the art to use a system frame header and the data packet 
protocol header format of a TFTP data packet in sending data packets in the invention of 
Klimenko. It also would have been obvious to include the filename, normally only included in 
the TFTP RRQ packet, in the header of the data packet. One of ordinary skill in the art would 
have been motivated to use the system frame header and data packet protocol header to be 
compliant with the TFTP standard. One of ordinary skill in the art would have been motivated to 
include the filename in the TFTP data packet header so that the NIC on the client computer 
would be able to determine which packets belong to which file if more than one file is being 
downloaded. 
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Regarding claim 7, Klimenko fails to disclose that the acknowledgement packet consists 
essentially of a system frame header, and acknowledgement code, and a block number. RFC 783 
discloses a format for an ACK packet that contains an opcode, which represents the 
acknowledgement code, and block # (see Figure 5-3, page 10). The system frame header is 
shown in Figure 3-1 (page 5). At the time the invention was made, it would have been obvious 
to a person of ordinary skill in the art to use this format of an acknowledgement packet in 
acknowledging the received file from the server in the invention of Klimenko. One of ordinary 
skill in the art would have been motivated to do this so that the server would know which packets 
have been sent successfully and which ones need to be retransmitted. 

Regarding claims 8 and 10, Klimenko discloses a media access control (MAC) address of 
the NIC that is 12 characters long in hexidecimal format, or 6 bytes long if represented in binary 
(col, 10, line 5). The server also has a MAC address (col. 1 1, lines 35-37). Klimenko fails to 
disclose a system frame header that specifies the addresses of the router card and system 
controller. RFC 783 discloses a system frame header composed of Local Medium and Internet 
headers (Figure 3-1, page 5). At the time the invention was made, it would have been obvious to 
send the MAC addresses of the NIC and server in the Local Medium part of a system frame 
header in the invention of Klimenko. One of ordinary skill in the art would have been motivated 
to do this so that the packet would be routed to the correction destination NIC and that the 
receiving NIC was sure that this packet was coming from the server. 

Regarding claims 1 1, 12, 39, 42, 44 and 47, Klimenko discloses a media access control 
(MAC) address of the NIC that is 12 characters long in hexidecimal format, or 6 bytes long if 
represented in binary (col. 10, Hne 5). The server also has a MAC address (col. 11, lines 35-37). 
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Klimenko fails to disclose a system frame header that specifies the addresses of the router card 
and system controller, a request code, and a file type in the request packet. RFC 783 discloses a 
system frame header composed of Local Medium and Internet headers (Figure 3-1, page 5). 
RFC 783 also discloses a request packet format that includes an opcode, which is the request 
code of the present invention, and a filename, which represents the file type of the present 
invention (see Figure 5-1, page 8). At the time the invention was made, it would have been 
obvious to send the MAC addresses of the NIC and server in the Local Medium part of a system 
frame header in the invention of Klimenko. It also would have been obvious to include a request 
code and the file type in the request packet. One of ordinary skill in the art would have been 
motivated to do this so that the packet would be routed to the correction destination NIC and that 
the receiving NIC was sure that this packet was coming from the server. One would have been 
motivated to include the request code and file type to be compliant with the TFTP format of a 
request packet. 

Regarding claim 13, Klimenko discloses that the process of downloading a boot file 
occurs after a user has powered-up client PC (10), which includes the NIC (col. 9, lines 56-66). 
It is inherent that if the chent PC is powered-up it was at some point previously powered-off. 

Regarding claims 14 and 15, Klimenko discloses that the process of downloading a boot 
file occurs after a user has powered-up client PC (10), which includes the NIC (col. 9, hnes 56- 
66). It is inherent that if the client PC is powered-up it was at some point previously powered- 
off. 
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Conclusion 



4. 



The prior art made of record and not relied upon is considered pertinent to applicant's 



disclosure. 



- Sposato (US 6,463,530) Method and Apparatus for Remotely Booting a Client 
Computer from a Network by Emulating Remote Boot Chips 

- Khanna et al. (US 2003/0200273) Console Redirection Among Linked Computers 

- Hayes, Jr, (US 6,205,476) CUent-Server System with Central Application Management 
Allowing an Administrator to Configure End User Applications by Executing Them in the 
Context of Users and Groups 

5. Any inquiry concerning this communication, or earlier communications from the 
examiner should be directed to Thomas Volper whose telephone number is 703-305-8405 and 
fax number is 703-746-9467. The examiner can normally be reached between 8:30am and 
6:00pm M-F. 

If attempts to reach the examiner by telephone are unsuccessftjl, the examiner's 
supervisor, Huy Vu, can be reached at 703-308-6602. Any inquiry of a general nature or relating 
to the status of this application or proceeding should be directed to the receptionist whose 
telephone number is 703-305-4750. 

Thomas E. Volper 



May 28, 2004 
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